Date: Sat, 21 Aug 93 04:30:18 PDT
From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
Errors-To: Ham-Digital-Errors@UCSD.Edu
Reply-To: Ham-Digital@UCSD.Edu
Precedence: Bulk
Subject: Ham-Digital Digest V93 #15
To: Ham-Digital
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                       Autopatch (phone patch)
                          Digital Hierarchy
                              Small TNC
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Problems you can't solve otherwise to brian@ucsd.edu.
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We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 21 Aug 1993 08:17:04 GMT
From: news.cerf.net!nic.cerf.net!patrick@network.ucsd.edu
Subject: assistance: modem <-> x-mitter/receiver link
To: ham-digital@ucsd.edu

In article <CC3CCu.2I6@NeoSoft.com> sengle@blkbox.COM (Steven W. Engle) writes:
>I need to link two computers together via a wireless link. 
>... (all sorts of stuff omitted)  ...
>Steve Engle
>sengle@blkbox.com
>

It might be worth rethinking your design.  A frequently used technique
for close wireless communciation is via infra-red transmitters and receivers;
exactly the way your remote control talks to your VCR.  A simple circuit
including a UART for parallel to serial conversion and an IR transmitter/
receiver for the wireless link can provide an easy to program two
way link which works as long as the IR beam reaches both stations.
It would also seem feasable to use a standard RS-232 port for the
serial communication by simply adapting an IR link between the two
computers' ports.  I recommend consulting historic Radio and Electronics
magazines for more specific part number and circuit information.

Hope this helps!

-patrick@cerf.net

------------------------------

Date: 20 Aug 93 17:59:15 GMT
From: news-mail-gateway@ucsd.edu
Subject: Autopatch (phone patch)
To: ham-digital@ucsd.edu

I would like to buy an autopatch (phone patch) in order to set up 
a mobile phone using two handhelds (Icom 24AT).

Conveying your recommendations and sharing your experience in this 
regard will be very much appreciated.

Does anyone know of the regulations for using autopatch?


Many thanks in advance

Regards, 
	Ali Taalebi
	taalebi@ai.mit.edu

------------------------------

Date: 19 Aug 93 06:42:03 GMT
From: rtech!amdahl!amdahl!ikluft@decwrl.dec.com
Subject: Digital Hierarchy
To: ham-digital@ucsd.edu

[Followups to rec.radio.amateur.digital.misc]

ben@nj8j.atl.ga.us (Ben Coleman) writes:
>Of course, the question will be(consider this a preview of what the 
>discussion will look like in news.groups when this RFD gets cranking in a 
>few months):  is there sufficient traffic to justify the new groups?  

Yeah, agreed.  When you propose a new newsgroup, you need to *know* that
you're putting your proposal out to some very skeptical masses that could,
and probably will, tear it apart.  Of course, I'm not saying that's bad - the
net would be a big mess (well, bigger mess than it is :-) if it wasn't
difficult to make a new newsgroup.

>Obviously, there will be another try at creation of rrad.tcpip.  Based
>on what I've seen recently, rrad.packet will probably be in the running 
>also.  But is there really enough RTTY, AMTOR, or PACTOR traffic on here to 
>justify a separate newsgroup for them?  In the end, I think they will be 
>left to rrad.misc until enough long-term traffic shows up to justify 
>creating separate groups.

I also would not be surprised if another try is made at r.r.a.d.tcpip.  But
there was already quite a bit of resistance at moving the r.r.a.packet to
r.r.a.d.misc.  I'll go with the flow on a r.r.a.d.packet but I would not
look forward to the mess that will cause with the mail lists again.

Anyway, it's still a long way off.  Ben mentioned this but I'll expand on it.
r.r.a.d.tcpip failed the last vote so it has to wait 6 months before anyone
can try again.  That will be January 1, 1994 for the earliest possible
posting of a Request for Discussion (RFD).  Assuming that goes well, it will
be 21-30 days before voting can begin, which would also be 21-30 days.  So,
no matter how enthusiastic anyone is for it, it can't happen before February
or March of next year.  So be patient... let's properly settle into the new
groups we just got before jumping to make more.

If anyone's interested, I'd expect that the initial discussion for an RFD will
happen on the "rec.radio.amateur working group" mail list - a collection of
the volunteers who post periodic informational articles & FAQs, the moderator
of rec.radio.info, some ARRL staff, and other regular participants in the
rec.radio.amateur newsgroups.  If you think you'd like to be a part of it
or just watch, it's always open for you to join.  Just send a message to
rra-wg-request@amdahl.com and ask to join the list.  Don't forget to include
your callsign so you can be properly introduced to the group.
-- 
Ian Kluft  KD6EUI PP-ASEL         Amdahl Corporation, Open Systems Development
ikluft@uts.amdahl.com                                          Santa Clara, CA
[disclaimer: any opinions expressed are mine only... not those of my employer]

------------------------------

Date: 20 Aug 93 18:01:30 GMT
From: news-mail-gateway@ucsd.edu
Subject: Small TNC
To: ham-digital@ucsd.edu

   Trond (trond@phys.ucalgary.ca)   writes:   

   >I would like to go portable on packet and now I wonder what is the
   >(physically)
   >smallest TNC available?  I will only need to be active on vhf/uhf.
   >Power consumption is also an important factor.
   >It seems to me that a tnc could be made extremely small...

   >I have not been looking in mags/brochures for years, 
   >so I have lost touch with
   >what the state of the art is. :-)

   >73
   >Trond

You probably have heard about the software based TNC's such as BayPac and 
"Poor Man's Modem". 

Besides those, there is a small self-contained TNC called AR210
(export version of the TNC-210 made by Tasco, Japan).

It it the improved version of the TNC-u II or 
HK21 (which used to be sold in the US by Heath Kit). 

Some specs are:
 
- ac/dc plug on the back (10-13 V, 100 mA),
- can run on a rechargeable battery ($20 extra!)
- supports the KISS mode,
- 1200 baud,
- cabel ready for Handhelds,
- 60mm(W) x 100mm(L) x 20mm(H),
- 9 pin serial port on the back (HK21 was 25 pin!),
- front panel accomodates the power switch, LED's and R/T plugs.

Note: As opposed to the HK21, there is no removeable chips inside.
      The new surface-mount technology is used!


Henry Radio in California (800-877-7979) sells it for 
$180 (rechargeable battery and adaptor not included).
It seems expensive to me, however I like its compactness and neat packaging.

If you decide to buy one, make sure to ask them to include the manual.
They forgot to send me the manual.


--73's de N1HPP
============================================================
      __   _	M. Ali Taalebinezhaad,
    /   ) //	The Canadian Institute 
   /- -/ // o   	for Robotics and Intelligent Systems
  /   /_</_<_	Phone: (418) 656-2131 (Ext. 8026)
		Fax:   (418) 656-3594
		Email: taalebi@gel.ulaval.ca
		Addr.: Robotics & Vision Laboratory
 		       Pouliot Bld., Room 00114
		       Elec. Eng. Dept., Laval Un.
		       Quebec, PQ, G1K-7P4, Canada
============================================================

------------------------------

Date: Thu, 19 Aug 1993 17:59:14 GMT
From: nntp.ucsb.edu!mustang.mst6.lanl.gov!nntp-server.caltech.edu!news.claremont.edu!ucivax!news.service.uci.edu!usc!sdd.hp.com!portal!lhaven.UUmh.Ab.Ca!combdyn!lawrence@network.ucsd.edu
To: ham-digital@ucsd.edu

References <24s89t$53v@vixen.cso.uiuc.edu>, <24th89$9e0@usenet.INS.CWRU.Edu>, <willmore.745692273@metropolis.gis.iastate.edu>ice.uc
Subject : Re: TCP/IP and unix machines

In article <willmore.745692273@metropolis.gis.iastate.edu> willmore@iastate.edu (David Willmore) writes:
>From my reading I would say that encryption is not allowed, but crypto used
>for authentication is ok.  As long as you're only proving who you are and not
>telling anyone anything (sending a message) I don't think that there would
>be any conflict.  Think about access to a autopatch.  You have to have a code
>to access it, what's the difference?
>
Yeah, but the code can't stay a secret to access the autopatch....anybody with
a DTMF decoder can figure out what the autopatch (or linking) codes are.  They
can also figure out what number you are dialing.


-- 
 --EMAIL-----------------------------PHONE-----------FAX------------
 | WORK: lawrence@combdyn.com      | (403)529-2162 | (403)529-2516 | CallSign
 | HOME: dreamer@lhaven.uumh.ab.ca | (403)526-6019 | (403)529-5102 |  VE6LKC
 -------------------------------------------------------------------
  disclamer = (working_for && !representing) + (Combustion Dynamics Ltd.);

------------------------------

Date: Thu, 19 Aug 1993 17:51:47 GMT
From: gecko!lanzo@uunet.uu.net
To: ham-digital@ucsd.edu

References <24pqjc$nk3@vixen.cso.uiuc.edu>, <24rs1b$icc@usenet.INS.CWRU.Edu>, <24s89t$53v@vixen.cso.uiuc.edu>com
Reply-To : lanzo@tekelec.com
Subject : Re: TCP/IP and unix machines

In a prior article ...green spleen... <dobrowol@ux1.cso.uiuc.edu> wrote:

  [ prior discussion omitted ... ]

  > What I meant to ask was how passwords are sent over packet. 
  > Wouldn't others 
  > be able to "see" a user's password if they were just sent over the 
  > air 'as is'?

Absolutely.  If you are concerned about privacy, then amateur
packet radio is the wrong place for you.  All of the data 
sent between stations is "in the clear", so you certainly
wouldn't want to use it as the medium for transferring any
"delicate" information.

There's not much we can do about this either under present
regulations, since using codes / cyphers or other things
whose purpose is to "obscure meaning" is forbidden.

Locally, most of our TCP/IP packet stations just use 
callsigns as the "login" id's, and the person's first
name as the "password" (or don't have one at all).
In fact, most of the stations here will accept any
callsign for the login-id -- the default is to let an
unrecognized user on without even bothering with a 
password.

Note though that this doesn't necessarily apply to whatever
Unix SW you are using.  The packet stations around here
which run TCP/IP usually are on Amigas or IBM-PCs running OS/2 --
and any notion of "user accounts" or "login ids" is something
maintained by the packet software, not the underlying OS.

I don't know about any Unix packet radio SW per se, but it
may well be the same -- that the packet radio "accounts"
exist purely within the packet radio SW (running under one
real Unix login probably) and aren't otherwise related
to Unix accounts.  On the other hand ....

Anyone wanna provide a synopsis of packet radio software
available for Unix systems and how it works?

+---------------------------------------------------------+------- /// -----+
| Mark Lanzo   KD4QLZ   lanzo@tekelec.com   919-460-5576  |    \\\///       |
+---------------------------------------------------------+---- \XX/ -------+

------------------------------

End of Ham-Digital Digest V93 #15
******************************
